Computer virtualization has dramatically altered the information technology (IT) industry in terms of efficiency, cost, and the speed in providing new applications and/or services. The trend continues to evolve towards network virtualization, where a set of tenant end points, such as virtual machines (VMs) and/or hosts, may communicate in a virtualized network environment that is decoupled from an underlying physical network, such as a data center (DC) physical network. Constructing virtual overlay networks using network virtualization overlay (NVO3) is one approach to provide network virtualization services to a set of tenant end points within a DC network. NVO3 is described in more detail in the Internet Engineering Task Force (IETF) document, draft-ietf-nvo3-arch-01, published Oct. 22, 2013 and the IETF document, draft-ietf-nvo3-framework-05, published Jan. 4, 2014, both of which are incorporated herein by reference as if reproduced in their entirety. With NVO3, one or more tenant networks may be built over a common DC network infrastructure where each of the tenant networks comprises one or more virtual overlay networks. Each of the virtual overlay networks may have an independent address space, independent network configurations, and traffic isolation amongst each other.
Typically, one or more default gateways may be setup for the virtual overlay networks within a tenant network to route data packets between different networks. For instance, a default gateway may route traffic between two virtual overlay networks located within the same tenant network and/or different tenant networks. Additionally, the default gateway may route traffic from a virtual overlay network to different types of networks, such as other types of virtual networks (e.g. virtual local area network (VLAN) and Internet Protocol (IP)-virtual private network (VPN)), a physical network, and/or the Internet. However, to route data traffic, the default gateway may maintain and enforce a variety of routing policies, such as inter-subnet forwarding policies and network service functions (e.g. firewall), in order to properly forward data traffic from a source end point to a destination end point. Unfortunately, as DC networks continue to expand, routing intra-DC traffic (e.g. data traffic forwarded within a DC network) using default gateways may not only cause sub-optimal routing, but may also produce processing bottlenecks caused by constant policy checking at the default gateways.